home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Shareware Grab Bag
/
Shareware Grab Bag.iso
/
001
/
exectele.arc
/
PCPXFER.TXT
< prev
Wrap
Text File
|
1979-12-31
|
3KB
|
59 lines
This message extracted from Exec-PC BBS 414-964-5160,
or PCP direct "C EXECPC,telenetid"
FROM: MICHAEL KEEFE
TO: SYSOP
SUBJECT: R: R: DOWNLOAD VIA PCP
DATE: 01-24-88 19:36
Evidently there is a great deal of problems/concerns regarding the
reliability of the PCP Direct connection. As a frequent user of this board
and others BBS's in the country that are PC Pursuitable, I have decided to
provide some hints for all regarding some problems noted and actual d/l
specifications. I hope that it helps.. Any comments, or prroblems I remain
more than happy to answer.
Parameters:
To PCPursuit (local) I connect at 7E1. Then the direct connection is
made to EXEC-PC (per instructions in EXECTELE.TXT). Once connected, I am
in the habit of switching to 8N1. All of the above is done with a 1200
baud (US robotics Courier) with Procomm v2.4.2.
Some problems noted:
At the outset, I must admit that not all of my downloads have been
flawless with using PCPursuit. I have found that the direct connection is
more reliable than the old approach (through Milwaukee node ...).
The download protocol which I used with the "old" approach was the
special (slowdown) Ymodem available here. However, with the direct
connection, I always use Ymodem.
It should be noted that the mere presence of a BAD CRC does not indicate
that the ARC is not good. I have found the Ymodem protocol to be
particularly well behaved in the "recovery of" errors (i.e. popping sounds,
electrical interference). After the file has been downloaded, use PKARC/V
to verbose list the ARC.
It is also important that you correctly identify the source of the "BAD
" archive download.
1. Is it the file itself (i.e., the file on EXEC-PC is corrupted: rare
but it does happen).
2. Is the problem "with the direct connect"
3. Is the problem with "normal PCPing" (i.e., old way)
4. Is the problem due to the download protocol
5. Is the probelm due to the communication software
6. Is the problem due to the hardware (i.e., loose RS232, CB
interference)
One particular anamoly that I have found concerns certain ARCs that have
several files in them that have been squashed. While I was unable to
pinpoint the necessary conditions, PCP seems to dislike squashed files that
are approximately 512 bytes large or less. You are made aware off this
condition when your computer begins to beep for approximately 3 minutes and
then drops you to the node level ("@"). In order to get around this
problem, I have patched PKARC tochange the default archive standard to be
crunching. This file is available on this board (search for PKARC).
After you PKARC/F the archive, the error no longer occurs on upload.
If you are still having problems, please feel free to leave a message for
either myself (or address one to Bob Mahoney and he will direct you to
myself). I will be happy to elaborate further.
mike